You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Aug 8, 2023. It is now read-only.
MGLTileSet’s attribution property – which may soon live on MGLTileSource; see #7360 – should be an array of objects containing structured attribution information. We can use the MGLAttributionInfo class being added in #5999 to represent a single attribution item.
The current MGLTileSet.attribution property is a single string containing HTML code. This encourages developers to manually craft HTML strings, which can be error-prone. It also means any developer who wants to make sense of a preexisting attribution string would have to parse it as HTML. Done incorrectly, both operations can be avenues for HTML injection. Since #5999 already parses the HTML source code into structured attribution, I don’t think there’s really a use case for working with the raw source code as opposed to, say, an attributed string (which can always be converted back to HTML if needed).
Someday, once mapbox/tilejson-spec#20 is implemented, the SDKs will be able to take advantage of structured attribution in TileJSON with minimal changes and likely no changes to public-facing API.
We’re pulling this refactoring into the v3.4.0 milestone because most of the pieces are already in place and because we don’t want to have to make a backwards-incompatible change or deprecate a symbol just to expose MGLAttributionInfo publicly. This change will probably occur as part of #7377.
MGLTileSet
’sattribution
property – which may soon live onMGLTileSource
; see #7360 – should be an array of objects containing structured attribution information. We can use the MGLAttributionInfo class being added in #5999 to represent a single attribution item.The current
MGLTileSet.attribution
property is a single string containing HTML code. This encourages developers to manually craft HTML strings, which can be error-prone. It also means any developer who wants to make sense of a preexisting attribution string would have to parse it as HTML. Done incorrectly, both operations can be avenues for HTML injection. Since #5999 already parses the HTML source code into structured attribution, I don’t think there’s really a use case for working with the raw source code as opposed to, say, an attributed string (which can always be converted back to HTML if needed)./cc @boundsj @friedbunny
The text was updated successfully, but these errors were encountered: