[daisy] [skin2] Poll for participation and input

[Marc Portier]

forwarding a private reply that was obviously intended for the list,
with some comments inline...

hepabolu wrote:
> Marc Portier said the following on 28/9/07 17:05:
> 
>> I'm not entirely sure where the daisy html might be not valid
> 
>> there is however one clear issue that we're rather reluctant to solve: 
>> we feel that listing phantom xmlns attributes on elements as 'invalid' 
>> is quite over the top (and a consequence of the DTD heritage of HTML)
> 
> No, but xmlns attributes on the html tag that are simply leftovers from 
> pipeline processing could very well be removed.
> 
>> anyway, filtering out those might turn out a lot bigger (runtime) 
>> effort then gain...
> 
> Maybe: I've solved these warnings by adding a simple XSL that strips all 
> the namespaces just before the serializer in the html-DocumentPipe. This 
> might be optimized by looking at just the html tag.
> 
if xslt can do it, then it sounds like it could be added as a feature to 
the serializer

> Some other rather minor issues that could be solved design time:
> - add a 'type="text/javascript"' in layout.xsl
> - change the '&' to '&' in the links in menu.xsl
> 

could you make jira issues for these?
and if you've solved these, maybe provide solutions (preferably patch 
format)

> Of the 16 warnings I had on my page, these corrections solved 14.
> 
> The remaining warnings need more looking into, but I suspect they have 
> something to do with the HTML editor/HTML cleaning process.
> Before I get into this in more details I need to check the specs first. 
> I might come back to that.
> 

cool, thx

> Finally, there are some proprietary tags that fire off warnings, e.g. 
> 'partname' on an img tag. Would that be solved if you added these 
> attributes with a 'daisy' namespace?
> 
>> not entirely sure:
>> I find it often a plus that the editing environment looks similar to 
>> the display.  So I see it as a plus that I don't need to do the 
>> skinning work twice.
> 
> True, but where I would want to do extensive redesign of the display, 
> I'd rather stick to the provided layout in the editing environment. The 
> current XSL could be improved on which part is created by which 'template'.
> 
> You might create something like:
> 
> <xsl:template match="/">
>  <!-- figure out which environment we're in -->
>    <xsl:call-template name='buildpage' mode='display'/>
> 
>    or
> 
>   <xsl:call-template name='buildpage' mode='editing'/>
> </xsl:template>
> 
> <xsl:template name='buildpage' mode='display'/>
>   <xsl:call-template name="header"/>
>   <xsl:call-template name="content" mode ="display"/>
>   <xsl:call-template name="footer"/>
> </xsl:template>
> 
> <xsl:template name='buildpage' mode='editing'/>
>   <xsl:call-template name="header"/>
>   <xsl:call-template name="content" mode ="editing"/>
>   <xsl:call-template name="footer"/>
> </xsl:template>
> 
> etc....
> 
> This would provide a clearer idea of which part you want/need to modify.
> 
> 
>> However I do think we need clearer class/id markings so css files 
>> would know as well in which mode pages currently are...
> 
> Agree.
> 
>> maybe we should even prefix with dsy-id- (as other dsy- prefixes might 
>> be useful)
> 
> Fine by me.
> 
>>> - something that still eludes me: what is the purpose of specific 
>>> documentTypes? To me they hold a specific type of content, e.g. news 
>>
>> each of them typically has a different set of fields/parts
> 
> Ok, but to me, this should be based on content, not on layout issues.
> 

sorry, but I think you're reversing the burden of proof here

document-types _are_ about content, not about styling
unless you chose to

as I said before:

> 
>> xslt can react on other properties of the document as well if you'ld 
>> prefer that
> 

IMHO technically just about any meta-data field can be used to drive 
styling, it's just that Daisy provides an easy way for doing it based on 
the doctype since it is a very common use case to give things a 
different look based on _what they are_

but if you think something else should drive the styling: then you can 
implement that as well

maybe you can elaborate on what else should drive the style in your 
case, and how a new skin could help you with that?

> [Random thinking here]
> To discriminate between two 'sections' in one document, e.g. to move 
> them around, they need to be in separate <div>'s. AFAIK I cannot add a 
> <div> to the HTML in a part, because it's stripped out, so I need to add 
> it in in the layout.xsl. This forces me to create a separate part.
> 
> OTOH: the information in the sidebar is usually of a different nature 
> than the main content, which would warrant a separate part.
> 

indeed
styling needs to be based on some semantical element to start with

what you ask for above is being able to apply those semantics inline in 
one part, note that the editor currently supports this kind of working 
to some level with the 'warn|note|fixme' styles

still, the sidebox sample in my head really calls for a separate part as 
well.

>>> table.tableMarkup { .... }
>>
>> or .daisyHtml table {....}
> 
> True, but you might want to discriminate between tables which would be 
> easier if tables have classes themselves.
> 

they have, and also note:
./daisywiki/webapp/daisy/resources/skins/default/table-classes.xml

(your skin should be able to list your set of table-classes for editors 
to pick from)

>>> - start off with a CSS framework. This is more or less also described 
>>> at the Yahoo site, mentioned in this thread. 
> 
> The mentioned frameworks are great, but they require a study of their 
> own. It would be nice to provide a simple example like I described in 
> the previous post.
> 
>> as andreas mentioned 'touching' the parent-xslt for all query styling 
>> should suffice (otherwise cocoon doesn't notice that he should 
>> recompile the xsl)
> 
> Ok, I remembered reading about it (and forgetting about it ;-) ).
> 
>>> - we need a simple fall back mechanism. The current 'add the name of 
>>> the default skin to file XYZ' is much better than before, but not 
>>> very intuitive.
>>
>> I think it's quite ok, and only needs clear documentation of the 
>> baseskin.txt file
>>
>> but I might be missing something and would surely like to learn any 
>> suggestions...
> 
> Hmm. I'm thinking about it. One thing that I'm about to run into in a 
> project: can I do this recursively, i.e. skin2 is based on skin1 which 
> is based on the default skin.
> 

yes

>> have started listing ideas in some organized way at 
>> http://cocoondev.org/wiki/521-cd/522-cd.html
>>
>> please add if I missed something
> 
> I want to, but I can't find the link to enter the editing environment. 
> What am I missing? And yes, I'm logged in.
> 

you were missing the proper rights to write in the wiki section,
(you've got them now)

regards,
-marc=