[dev] [commits] Horde-Hatchery branch master updated. 1a57ad3e16e1a3e92b0f087ba1765c9089c48577

Jan Schneider jan at horde.org
Sun Sep 27 22:32:56 UTC 2009


Zitat von Michael M Slusarz <slusarz at horde.org>:

> Quoting Chuck Hagenbuch <chuck at horde.org>:
>
>> Quoting Michael M Slusarz <slusarz at horde.org>:
>>
>>>> Quoting Jan Schneider <jan at horde.org>:
>>>>
>>>>> Zitat von Michael M Slusarz <slusarz at horde.org>:
>>>>>
>>>>>> The branch "master" has been updated.
>>>>>> The following is a summary of the commits.
>>>>>>
>>>>>> from: 94553bd518124a2f1d9347f618077e313b1dcb5c
>>>>>>
>>>>>> d90ce60... Fix adding phishing status info
>>>>>> 5229eff... This style has been moved inside the HTML viewer.
>>>>>> 1a57ad3... Correctly show phishing highlighting when viewing inline
>>>>>
>>>>> We should rather move HTML/CSS code *out* of the PHP libraries,  
>>>>> rather than adding more. I understand the rationale, but this is  
>>>>> really not the direction we should take.
>>>>
>>>> I strongly agree, though I think there is probably a place for  
>>>> packages to come with some default views (which could be  
>>>> overridden of course). That way we get HTML out of the classes,  
>>>> but we can still bundle re-useable UI bits. I'm happy to help  
>>>> move these things to View partials.
>>>
>>> This is a special case.  Or else, we have to inject our entire CSS  
>>> into the IFRAME.  And not having our CSS visible to the HTML data  
>>> is sort of the whole reason why we are using an IFRAME.
>>
>> Right, but why not provide the HTML and CSS in a template that  
>> users of the library can override?
>
> Guess I am really confused.  For the HTML driver, what HTML is there  
> to override outside of the IFRAME declaration (which *can't* be  
> overriden, and is exactly the sort of item that shouldn't be in a  
> template)?
>
> And as mentioned before, we can't introduce any CSS classes to the  
> HTML data because there is no guarantee that these declarations  
> won't conflict with existing class/ID names in the HTML data.  And  
> how would we convert user specified CSS into a valid style string?   
> Via a CSS parser or some other resource-intensive task?  No, thank  
> you.

Yeah, makes sense.

> Maybe doing some sort of view abstraction makes sense for other  
> drivers, but not for the new HTML driver.

Jan.

-- 
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/



More information about the dev mailing list