This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Art reminded me about this one, so here is a proper bug. In http://www.w3.org/TR/dom/#interface-domerror [[ On 7/10/14 12:25 PM, Glenn Adams wrote: > The language "nuked from orbit soon" and "will be nuked" needs to be > rewritten. This level of informality is inappropriate for a W3C REC > track document. Better to say "expect to be deprecated" or similar. I agree with this proposal (particularly since "nuke" might not translate accurately). > It is annoying that a search for "Warning!" in the document fails (at > least on Chrome and Firefox) because it is injected from a content > style property. This seems a bit like a personal preference to me. As such, I don't think it should block the LCWD publication although if Glenn created a PR that was agreeable to Robin, then I don't see any harm in merging it. > There remains a normative reference to the WHATWG "URL" specification, > which needs to be resolved before moving to REC. It would be well > advised to describe the expected process for doing this in the SoTD > section. I don't think this point should block publication of a LCWD. (I also think the reference policy [1] describes a way to handle this for subsequent publications.) ]]
(In reply to Philippe Le Hegaret from comment #0) > Art reminded me about this one, so here is a proper bug. > > In > http://www.w3.org/TR/dom/#interface-domerror > > [[ > On 7/10/14 12:25 PM, Glenn Adams wrote: > > The language "nuked from orbit soon" and "will be nuked" needs to be > > rewritten. This level of informality is inappropriate for a W3C REC > > track document. Better to say "expect to be deprecated" or similar. > > I agree with this proposal (particularly since "nuke" might not > translate accurately). +1 - this needs to be changed. THe change is completely editorial as long as the warning remains intact. Please change this. > > > It is annoying that a search for "Warning!" in the document fails (at > > least on Chrome and Firefox) because it is injected from a content > > style property. > > This seems a bit like a personal preference to me. As such, I don't > think it should block the LCWD publication although if Glenn created a > PR that was agreeable to Robin, then I don't see any harm in merging it. Actually, it is an A11Y concern. Text that comes in via CSS is often missed by screen readers. This text should be inline in the document so that it appears in the DOM. There are many sources for such information about those limitations, including guidance from the W3C. For a decent non-standards article about just why it is bad, see http://www.ssbbartgroup.com/blog/csscontentproperty/
> > > It is annoying that a search for "Warning!" in the document fails (at > > > least on Chrome and Firefox) because it is injected from a content > > > style property. > > > > This seems a bit like a personal preference to me. As such, I don't > > think it should block the LCWD publication although if Glenn created a > > PR that was agreeable to Robin, then I don't see any harm in merging it. > > Actually, it is an A11Y concern. Text that comes in via CSS is often missed > by screen readers. This text should be inline in the document so that it > appears in the DOM. There are many sources for such information about those > limitations, including guidance from the W3C. For a decent non-standards > article about just why it is bad, see > http://www.ssbbartgroup.com/blog/csscontentproperty/ +1 to the accessibility concerns here. Agree that it is not sufficient to stop progress *at this time*, but reserve the right to come back to this as a blocker for Rec Status. Philippe, should this concern be moved to a new bug? Happy to file it.
(In reply to Philippe Le Hegaret from comment #0) > I don't think this point should block publication of a LCWD. (I also > think the reference policy [1] describes a way to handle this for > subsequent publications.) > ]] W3C specs can point to WHATWG specs. We don't need to humor Glenn on this point.
Please don't use this component to file bugs on out-of-date forks. This word does not appear in https://dom.spec.whatwg.org/ as far as I can tell. I would appreciate a GitHub issue on the a11y concern, which you can file here: https://github.com/whatwg/dom/issues/new I think we need to make some changes to our stylesheet and tooling for that which might get a bit involved, but shouldn't be too problematic.
(In reply to Anne from comment #4) > Please don't use this component to file bugs on out-of-date forks. This word > does not appear in https://dom.spec.whatwg.org/ as far as I can tell. I think this is filed here because DOM4 within the W3C is going through a CfC to transition to Proposed Recommendation. It is possible the static version that is trying to become a Rec has diverged from the WhatWg version of course. This should *note* be marked as resolved in that context, IMHO. > I > would appreciate a GitHub issue on the a11y concern, which you can file > here: https://github.com/whatwg/dom/issues/new I will try to write up something cogent there.
Created attachment 1615 [details] Screenshot that shows warning character doesn't display
(In reply to Anne from comment #4) > I > would appreciate a GitHub issue on the a11y concern, which you can file > here: https://github.com/whatwg/dom/issues/new > > I think we need to make some changes to our stylesheet and tooling for that > which might get a bit involved, but shouldn't be too problematic. FYI I discussed this with the W3C PFWG today and the group believes that this issue has been overcome by events in modern browsers that conform to WAI-ARIA. The PFWG still believes that having content inline is the preferred way of providing that content, but regardless content that is inserted via CSS does get exposed through the various Accessibility APIs in modern user agents.