User Tools

Site Tools


design:html-requirements

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
Last revision Both sides next revision
design:html-requirements [2014/09/15 12:59]
rsewikiadmin
design:html-requirements [2014/09/17 07:18]
rsewikiadmin Note: items deleted from the list were overtaken by events and are no longer a problem
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." Can we phrase this in terms of +
-> what the converter is expected to do instead?+
  
 > 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.  At the very end, we will have a complete list, but not now (and that's ok).
  
 ====== ======
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, don’t want it compressed or smooched up one line
  
 > 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). 
 +
 +  * 
  
 ====Other open issues==== ====Other open issues====
Line 125: Line 138:
 > attributes get placed, or something else?  > attributes get placed, or something else? 
  
 +
 +> The document says "Additionally, anchors expressed in the source XML should 
 +> be exposed as anchors in the HTML as well." I suggested in my nits message 
 +> striking "Additionally," and "as well". But it occurs to me that the document 
 +> 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's text that says to wrap section numbers in an 
 +> <a class='self-ref' href=...>. I suspect this should apply to other <a href> 
 +> that are generated?
 +
 +> The paragraph that begins "For other block items, such as <figure>, <t>, 
 +> and <texttable> is talking about XML, not HTML. Can it be rewritten more 
 +> specifically in terms of input and output? 
  
design/html-requirements.txt · Last modified: 2014/09/17 07:28 by rsewikiadmin