[TYPO3-dev] Master Style 4 Typo3

Christopher bedlamhotel at gmail.com
Tue Feb 21 16:58:10 CET 2006


On 2/21/06, Ries van Twisk <typo3 at rvt.dds.nl> wrote:
> Franz Koch wrote:
>
> >>>h1/h2 are already different tags, no need to use a class for that....
> >>>
> >>>
> >+1
> >
> >
> >
> >>CSS already offers excellent ways to 'drill down' to a specific content
> >>element. The main thing is to wrap the ext object in an id'd div once. Then
> >>leave the rest up to css. In this way, each object can be overstyled or
> >>left naturally styled depending on your preference.
> >>
> >>#ext_thing h1 {}
> >>
> >>etc. Less is more.
> >>
> >>
> >
> >Well, and what do you do if you have to place the same extension twice
> >on one page? Then the extension renders two elements with the same ID
> >which is not valid at all. Extension-wrappers can always only be classes
> >in my eyes.
> >If you need unique IDs, wrap the content-elements with the uid it it
> >isn't allready standard for 4.0. You need his anyway for valid XHTML as
> >a-tag anchors are invalid.
> >
> >
> >
> That was indeed my problem... But with flex elements in templavoila that
> gets show twice....
> So I try to stick with what I call "base ID's" Id's for headers and
> footers and main areas, things I know for SURE will only pop up once in
> my design, then again... way not use classes for design only and ID for
> identification for the design which sounds like a good design rule for
> layout build into CMS systems…
>

You guys are right about the cases (many!) where a plugin may appear
twice on a page--ids _must_ only appear once, after all. However the
larger point was not about ids/classes per-se, but about how many css
identifiers to put in the markup in the first place.

Id or class notwithstanding, markup like this is what we want to shoot for:

<div class="someexttensionoutput>
  <h1>Lorem Ipsum</h1>
  <p>Dolor sit amet</p>
  <ul>
    <li>Consectetur</li>
    <li>Adispicing</li>
  </ul>
</div>

...because all of the html elements inside it can be targeted using
the parent class:

.someextensionoutput h1 { ... }
.someextensionoutput p { ... }
.someextensionoutput ul { ... }
.someextensionoutput li { ... }

...etc.

I'd also like to suggest that using the uid in a css id is for most
purposes not particularly convenient--what if the uid has to change?
This idea will only work in cases where the extension is outputting
both the markup AND the css.


-Christopher




More information about the TYPO3-dev mailing list