| 01:02 | <othermaciej> | Does HTML have an authoring requirement that authors must not use unknown elements (ones that are not explicitly allowed, or a custom element)? |
| 01:02 | <othermaciej> | If so, can someone point me to it? |
| 01:02 | <othermaciej> | (or similarly for attributes) |
| 01:04 | <othermaciej> | I see "Elements must not contain content that their content model disallows." |
| 01:04 | <othermaciej> | In https://html.spec.whatwg.org/#elements-2 |
| 01:04 | <othermaciej> | Don't see anything more on-point |
| 01:05 | <MikeSmith> | othermaciej: https://html.spec.whatwg.org/#semantics-2:other-applicable-specifications |
| 01:05 | <MikeSmith> | > Authors must not use elements, attributes, or attribute values that are not permitted by this specification or other applicable specifications, as doing so makes it significantly harder for the language to be extended in the future. |
| 01:08 | <a-ja> | "must" in lowercase, eh? ;) |
| 01:09 | <MikeSmith> | yeah because it’s always normative |
| 01:10 | <MikeSmith> | we have a linter that finds and reports errors for use of any RFC 2119 keywords in non-normative text |
| 01:10 | <MikeSmith> | including “should” and “may” |
| 01:12 | <a-ja> | now if only various frameworks would stop inventing their own attributes |
| 01:16 | <othermaciej> | MikeSmith: thanks! |
| 01:17 | <MikeSmith> | othermaciej: cheers |
| 01:17 | <a-ja> | one i noticed the other day: JSX className |
| 01:17 | <MikeSmith> | a-ja: the problem is that we still lack any standard way to define custom attributes |
| 01:18 | <MikeSmith> | other than data-*, which is for a different purpose |
| 01:19 | <MikeSmith> | see the discussion and proposals at https://github.com/whatwg/html/issues/2271 |
| 01:20 | <MikeSmith> | personally the syntax that seems to make the most sense to me is to have the spec define underscore-prefixed attributes as custom |
| 01:20 | <MikeSmith> | and I think that is what Angular is doing these days |
| 01:21 | <MikeSmith> | or at least one of the ways that Angular allows (they seem to have a pattern of having multiple ways to do the same thing) |
| 01:39 | <a-ja> | MikeSmith, semi-related question, at what point do new attributes get added to checker/validator? |
| 01:42 | <a-ja> | e.g., FPWD Personalization Semantics has like a half-dozen with "aui-" prefix |
| 01:46 | <a-ja> | (formerly had "coga-" prefix) |
| 02:32 | <MikeSmith> | a-ja: sorry, was away dealing with another thing |
| 02:33 | <a-ja> | np....so was I |
| 02:33 | <MikeSmith> | heh |
| 02:34 | <MikeSmith> | attributes only get added to teh checker if they get added to the HTML spec or a spec referenced by the HTML spec |
| 02:35 | <MikeSmith> | and even then I don’t usually add them until some browser engines actually support them (in the case of attributes that have UA requirements) |
| 02:35 | MikeSmith | looks up Personalization Semantics |
| 02:38 | <MikeSmith> | OK I see https://www.w3.org/TR/personalization-semantics-1.0/#a-2-wai-aria |
| 02:38 | <MikeSmith> | > Properties in this case can be represented as WAI-ARIA properties by adding the prefix "aui-" to the attribute name, and the property value as the attribute value. |
| 02:38 | <MikeSmith> | but then also: |
| 02:38 | <MikeSmith> | The prefix above is not yet accepted by the ARIA Working Group. |
| 02:38 | <MikeSmith> | .. |
| 02:39 | <MikeSmith> | anyway for that one I guess I would wait til somebody finds it important enough to file a validator bug for |
| 02:39 | <a-ja> | just mentioned it as a heads up |
| 02:39 | <MikeSmith> | thanks |
| 02:39 | <MikeSmith> | I see the can also be expressed with Microdata or RDFa? |
| 02:40 | <a-ja> | parts, iirc. |
| 02:40 | <MikeSmith> | OK |
| 02:41 | <MikeSmith> | well if so, personally I hope the WG doesn’t end up accepting the aui- prefix stuff |
| 02:41 | <a-ja> | sounds like a job for schema.org |
| 02:41 | <MikeSmith> | yeah |
| 02:42 | <MikeSmith> | if it can be solved with that instead is should be |
| 02:42 | <MikeSmith> | and there’s already been plenty enough attribute proliferation from that domain |
| 02:42 | <MikeSmith> | well role values at least |
| 02:43 | <MikeSmith> | e.g., the massive number of DPUB role values that I got forced to add support for a while back |
| 02:45 | <a-ja> | i need to go read some to see what's happened since Daniel's suggestions |
| 04:56 | <MikeSmith> | Domenic: https://groups.google.com/forum/#!topic/mozilla.dev.platform/DZ7YctNoUUk (in case you didn’t see it already) |
| 04:57 | <MikeSmith> | > Intent to ship: Module scripts (ES6 modules) |
| 07:29 | <domfarolino> | \o/ |
| 11:22 | <annevk> | JakeA: not sure I'd call github.io GitHub, but fair enough |
| 11:22 | <annevk> | JakeA: https://github.com/robots.txt/ doesn't do it either |
| 11:23 | <annevk> | I wonder why they return 406 Not Acceptable for that |
| 11:24 | <JakeA> | annevk: ahh sorry, didn't realise you meant Github-proper |
| 14:11 | <nox> | . |
| 14:11 | <nox> | Mmh, keyboard focus fail. |
| 16:43 | <wanderview> | annevk: are you back from PTO? |
| 16:57 | <annevk> | wanderview: yeah, still quite a backlog end-of-day |
| 16:57 | <wanderview> | ok |
| 16:57 | <wanderview> | welcome back |
| 17:02 | <annevk> | wanderview: FWIW, from what I skimmed I’d favor preserving and exposing fragments |
| 17:02 | <wanderview> | annevk: even if we do it as a hidden bit to start? |
| 17:03 | <wanderview> | or just expose it fully |
| 17:03 | <wanderview> | I guess I can wait until you catch up |
| 17:03 | <annevk> | wanderview: I regret not investigating properly before |
| 17:03 | <annevk> | wanderview: fully, aiui |
| 17:03 | <wanderview> | ok |
| 17:04 | <wanderview> | annevk: I guess we need to wait on spec to change before updating WPT, though |
| 17:04 | <annevk> | wanderview: still need to read through your feedback on that properly though |
| 17:04 | <wanderview> | ok |
| 18:30 | <smaug____> | wpt tests are so nice. I wish we had started to write them since the beginning of the web |
| 21:52 | <railgun> | Domenic: is there an easy way to find out which page a section is in? I'd like to preview my changes for #2533 but don't know which page it's on |
| 21:54 | <MikeSmith> | railgun: I sometimes grep through the output dir |
| 21:54 | <MikeSmith> | or else just use the single-page output |
| 21:56 | <railgun> | MikeSmith: grep did the trick, thanks |
| 21:56 | <railgun> | I want to avoid the single page output since it takes a while to load for me |
| 21:56 | <MikeSmith> | OK |
| 21:57 | <MikeSmith> | oh btw, another way is to look at the id attributes in the diff |
| 21:57 | <MikeSmith> | locally |
| 21:58 | <MikeSmith> | if you do `git diff` it will show, e.g.: |
| 21:58 | <MikeSmith> | @@ -65656,8 +65656,8 @@ <h5 id="custom-elements-customized-builtin-example">Creating a customized built- |
| 21:58 | <MikeSmith> | for each chunk of the diff |
| 21:58 | <MikeSmith> | then if you copy that id and do this: |
| 21:58 | <MikeSmith> | http://html.spec.whatwg.org/multipage/#custom-elements-customized-builtin-example |
| 21:59 | <MikeSmith> | that will automatically redirect you to the right page |
| 21:59 | <MikeSmith> | of course use the file:// URL to your local output/multipage dir |
| 22:03 | <railgun> | MikeSmith: seems like the h4 tag in my git diff doesn't have an id attribute |
| 22:03 | <MikeSmith> | ah |
| 22:04 | <MikeSmith> | yeah a lot don’t, since the built generates them if they’re not explicitly inthe source |
| 22:05 | <MikeSmith> | but even in that case, given: |
| 22:05 | <MikeSmith> | @@ -109699,6 +109708,14 @@ <h5>Unclosed formatting elements</h5> |
| 22:06 | <MikeSmith> | you can do: |
| 22:06 | <MikeSmith> | https://html.spec.whatwg.org/multipage/#unclosed-formatting-elements |
| 22:06 | <MikeSmith> | ..because the build, to create the id in teh output, just takes that heading and lowercases and adds hyphens |
| 22:09 | <railgun> | yeah that works (it is important to note that it's case sensitive though) |
| 22:09 | <MikeSmith> | yup |