This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision Next revision Both sides next revision | ||
design:html-requirements [2013/10/17 11:11] rsewikiadmin |
design:html-requirements [2014/09/15 13:03] rsewikiadmin |
||
---|---|---|---|
Line 29: | Line 29: | ||
The abstract must be marked up or tagged in a way that search engines will extract it as summary. | The abstract must be marked up or tagged in a way that search engines will extract it as summary. | ||
+ | |||
+ | ==== Open items - September 2014 ==== | ||
+ | **Scope of the html document** | ||
+ | |||
+ | > There are sections that are really requirements for people writing | ||
+ | > xml2rfc v3. Those should be teased out into the grammar draft or | ||
+ | > draft talking about submission restrictions on the v3 format. | ||
+ | |||
+ | |||
+ | |||
+ | > 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 to do instead? | ||
+ | |||
+ | > Section 3.2.13 has what looks like instructions to authors: "If the | ||
+ | > quote needs a citation" | ||
+ | > terms of the XML. What should be here is what the HTML is expected to | ||
+ | > reflect from the XML. What XML do we expect to be input to result in the | ||
+ | > HTML example in that section? | ||
+ | |||
+ | |||
+ | ====== | ||
+ | **CSS requirements** | ||
+ | |||
+ | > "The only tags that may contain a ' | ||
+ | > give an explicit list). | ||
+ | |||
+ | |||
+ | ====== | ||
+ | **Basic HTML comments** | ||
+ | |||
+ | > 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). | ||
+ | |||
+ | > Section 3.1 disallows points like U+0009. Section 4 talks about | ||
+ | > compressing instances of U+0009 (and other disallowed points) into a | ||
+ | > single U+0020. | ||
+ | |||
+ | |||
+ | |||
+ | > Section 3.1 requires text containing elements be serialized as a single | ||
+ | > unwrapped line (to help with diffs). | ||
+ | > | ||
+ | > There is a separate requirement to indent children. (Thus there is an | ||
+ | > implicit requirement to start children on a new line.) | ||
+ | > | ||
+ | > Which of the following are we wanting to happen?: | ||
+ | > | ||
+ | > < | ||
+ | > | ||
+ | > or | ||
+ | > | ||
+ | > < | ||
+ | > < | ||
+ | > Your mileage may vary.</ | ||
+ | > | ||
+ | > Either way, the text needs to be made consistent and some examples would | ||
+ | > not hurt. | ||
+ | > Making the text consistent while dealing with nested lists may get gnarly. | ||
+ | |||
+ | |||
+ | |||
+ | > There are a couple of places where the document talks about non-div | ||
+ | > tags. I think this is from working in how we're going to place author | ||
+ | > provided and autogenerated ids. I don't think the distinction helps, and | ||
+ | > we can just say " | ||
+ | > also suspect we should be pulling out a section explicitly discussing | ||
+ | > these ids). | ||
+ | |||
+ | ====Other open issues==== | ||
+ | > What prefixes to use for autogenerated tags? | ||
+ | |||
+ | > Should an RFC style document encourage authors to use common tags for | ||
+ | > things like " | ||
+ | > help solve for the problem of intuitive pointers to common sections in | ||
+ | > RFCs? | ||
+ | (so far, Design Team has had one yes, one no) | ||
+ | |||
+ | > What reference to use (if any) for HTML5? | ||
+ | |||
+ | > Where is the line between indicating what the XML should do within the HTML | ||
+ | > for things like ASCII art, packet diagrams, etc, and what is appropriately | ||
+ | > just information for the XML draft? | ||
+ | |||
+ | > Should the HTML tags in the Appendixes stay (and get cleaned up) or be removed? | ||
+ | |||
+ | > | ||
+ | > Using classes instead of ids to aid with styling. | ||
+ | > This is a very good point. If others agree, I would propose that the current | ||
+ | > draft be changed from "< | ||
+ | > that we specify classes for all sections that seem to have special meanings. | ||
+ | |||
+ | > It's not clear what "same logic" in " | ||
+ | > the same logic as sections" | ||
+ | > attributes get placed, or something else? | ||
+ | |||
+ | |||
+ | > 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? | ||