design:html-requirements
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
design:html-requirements [2014/09/15 12:59] rsewikiadmin |
design:html-requirements [2014/09/17 07:28] (current) rsewikiadmin |
||
|---|---|---|---|
| Line 31: | Line 31: | ||
| ==== Open items - September 2014 ==== | ==== Open items - September 2014 ==== | ||
| + | Answer added where possible, per RFC Format Design Team call 16-September-2014 | ||
| + | |||
| **Scope of the html document** | **Scope of the html document** | ||
| Line 37: | Line 39: | ||
| > draft talking about submission restrictions on the v3 format. | > draft talking about submission restrictions on the v3 format. | ||
| - | + | * Joe will look at this; Paul notes that this assumes you have XML v3; Joe will need to work with Paul | |
| - | + | ||
| - | > In section 3.2.10, we say "The id will usually be machine-generated, | + | |
| - | > but MAY be human-readable if desired." | + | |
| - | > what the converter is expected | + | |
| > Section 3.2.13 has what looks like instructions to authors: "If the | > Section 3.2.13 has what looks like instructions to authors: "If the | ||
| Line 49: | Line 47: | ||
| > HTML example in that section? | > HTML example in that section? | ||
| + | * Joe will go through v3 draft and try to highlight what might impact HTML | ||
| ====== | ====== | ||
| Line 56: | Line 55: | ||
| > give an explicit list). | > give an explicit list). | ||
| + | * punt on that, this won’t help developers, and we’re likely to change our minds | ||
| + | * we will need guidance to say this is an exceptional situation; make sure that where you KNOW a style attrib needs to be explicitly placed, make sure to say so, and we will tell the developer “unless you see instruction to use style directly, don’t” | ||
| + | * There are style attributes, and things that inform style. | ||
| ====== | ====== | ||
| Line 62: | Line 64: | ||
| > It would be good to double-check that the currently deployed browsers | > It would be good to double-check that the currently deployed browsers | ||
| > treat that input as expected (at least at those we list as requirements). | > treat that input as expected (at least at those we list as requirements). | ||
| + | |||
| + | * this draft should say the RFC Ed will maintain a list of browsers we will be testing against, and strip the actual list out of the draft; post on the RFC Ed website and maintain there | ||
| > Section 3.1 disallows points like U+0009. Section 4 talks about | > Section 3.1 disallows points like U+0009. Section 4 talks about | ||
| Line 67: | Line 71: | ||
| > single U+0020. | > single U+0020. | ||
| + | * not applicable; this applied to submitters (which we won't have) not the tool | ||
| > Section 3.1 requires text containing elements be serialized as a single | > Section 3.1 requires text containing elements be serialized as a single | ||
| > unwrapped line (to help with diffs). | > unwrapped line (to help with diffs). | ||
| + | |||
| + | * all that was about stuff submitted as HTML; we should talk about what to indent with (spaces, not tabs) | ||
| + | * also, let’s keep the ease of diffs as a motive, because some people will want to run diffs against the HTML. | ||
| + | * Since we are building a diff tool for the XML, diff-ing the HTML will be less of a normal workflow case. | ||
| + | * So, remove any reference to wrapped text, and let the tools team do whatever and we’ll see what feedback we get | ||
| + | |||
| > | > | ||
| > There is a separate requirement to indent children. (Thus there is an | > There is a separate requirement to indent children. (Thus there is an | ||
| Line 89: | Line 99: | ||
| > Making the text consistent while dealing with nested lists may get gnarly. | > Making the text consistent while dealing with nested lists may get gnarly. | ||
| + | * Will probably pull out the whole indenting stuff too. | ||
| + | * Will put in something fuzzy about pretty-printed, | ||
| > There are a couple of places where the document talks about non-div | > There are a couple of places where the document talks about non-div | ||
| Line 97: | Line 108: | ||
| > also suspect we should be pulling out a section explicitly discussing | > also suspect we should be pulling out a section explicitly discussing | ||
| > these ids). | > these ids). | ||
| + | |||
| + | * Mention of non-div tags should be removed | ||
| ====Other open issues==== | ====Other open issues==== | ||
| > What prefixes to use for autogenerated tags? | > What prefixes to use for autogenerated tags? | ||
| + | |||
| + | * Heather to just pick something | ||
| > Should an RFC style document encourage authors to use common tags for | > Should an RFC style document encourage authors to use common tags for | ||
| Line 105: | Line 120: | ||
| > help solve for the problem of intuitive pointers to common sections in | > help solve for the problem of intuitive pointers to common sections in | ||
| > RFCs? | > RFCs? | ||
| - | (so far, Design Team has had one yes, one no) | + | |
| + | * How to write software that identifies security considerations? | ||
| + | * The only mandatory tag right now is for abstract. | ||
| + | * We can have two lists: one for mandatory, and one for suggested. | ||
| + | * Or maybe just make mandatory and see who complains. | ||
| + | * Paul to add something here in XML draft. | ||
| > What reference to use (if any) for HTML5? | > What reference to use (if any) for HTML5? | ||
| + | |||
| + | * leave that up to the RFC Editor what we’re currently tracking, similar to browsers. | ||
| + | |||
| > Where is the line between indicating what the XML should do within the HTML | > Where is the line between indicating what the XML should do within the HTML | ||
| Line 113: | Line 136: | ||
| > just information for the XML draft? | > just information for the XML draft? | ||
| - | > Should the HTML tags in the Appendixes stay (and get cleaned up) or be removed? | + | * Joe and Paul to review |
| > | > | ||
| Line 120: | Line 143: | ||
| > draft be changed from "< | > draft be changed from "< | ||
| > that we specify classes for all sections that seem to have special meanings. | > that we specify classes for all sections that seem to have special meanings. | ||
| + | |||
| + | * Joe might have a counter proposal; the one Paul has is a starting place that might work as well | ||
| + | * will have more info to make a decision after the id section is done | ||
| > It's not clear what "same logic" in " | > It's not clear what "same logic" in " | ||
| Line 125: | Line 151: | ||
| > attributes get placed, or something else? | > attributes get placed, or something else? | ||
| + | * Joe to to review | ||
| + | |||
| + | > The document says " | ||
| + | > be exposed as anchors in the HTML as well." I suggested in my nits message | ||
| + | > striking " | ||
| + | > needs to be more specific and reflect _how_ the source XML allows anchors to | ||
| + | > be expressed, and how those will be translated into the HTML. This falls, I | ||
| + | > think, into being clearer about author-provided and autogenerated ids. | ||
| + | > | ||
| + | > There' | ||
| + | > <a class=' | ||
| + | > that are generated? | ||
| + | > | ||
| + | > The paragraph that begins "For other block items, such as < | ||
| + | > and < | ||
| + | > specifically in terms of input and output? | ||
| + | * Joe and Paul to review | ||
design/html-requirements.1410811149.txt.gz · Last modified: 2014/09/15 12:59 by rsewikiadmin
Page Tools
